\section{Networking Design}
\label{networking_design}

We determined the role of the client networking component to be maintaining a connection with the server: reading commands from the command buffer and passing them to the server, and passing commands from the server to the client. These two concerns came with different challenges. Keeping a connection with the server involved considering how to manage writing and reading data to the socket, while allowing the client to run efficiently. Sending and receiving commands involved considering how best to parse data coming from the socket and pass data between components.

\subsection {Maintaining a Connection}

The connection to the server had to be designed such that our program could both freely write to the socket and receive commands without having to worry about concurrency. For example, the client should not have to worry about doing multiple writes to the server (or possibly simultaneous ones if there are any multithreaded aspects to its operations), or waiting for these actions to complete. With these considerations in mind, we had to design our component so that the socket would not be written to while a read or write was in progress. At the same time, it had to accommodate multiple requests. We had to implement this management in a way that these operations would be hidden from the client.

Our design ended up as follows. Writing to the network is handled by a thread that monitors the buffer for any commands to send to the server. Commands can accumulate in this buffer so that the client does not have to wait till a command has completed sending to continue its operations. As the methods in the buffer are synchronised, it is ensured that data remains in a consistent state, and that commands are sent sequentially. This is particularly important since the networking code uses this buffer to write to the server in order to implement the protocol's 'stay-alive' feature (as was discussed in section \ref{protocol_design}).

Reading from the network was handled by designing a class which we named `NetworkReader.' This class is run on a thread, and listens to the socket connection for incoming commands. When a command is received, it then places it onto the intermediate command buffer to be handled by the controller thread (as discussed in section \ref{controller}). The methods within the buffer class are designed to be thread-safe. A further role of the network reader class is to inform the client that the connection to the server has been broken, and that action must be taken to inform the user and reset any internal information.

\subsection {Command Handling}

The parsing of commands was a broad concern that affected both the server and client's activities. This motivated the need to design a `Command' class which could be used to parse commands. As described in the protocol design section, the GIM protocol follows a structured approach. For each command, it is possible to identify the command, argument, and data segments. The role of the Command class would be to parse incoming socket data into objects from which the individual segments of commands may be extracted. An additional responsibility of this class would be to convert images to and from base64 encoding for transmission over the network (as required by the GIM protocol).

We thought this was a sensible design decision as it provided a layer of abstraction. If the GIM protocol were to change, only the Command class would have to be edited. This led to the design of a `util' package as part of our project's structure, which included classes common to both the client and the server networking code. 

On creation of this command object by the `NetworkReader' class, it would be handed to the command buffer for retrieval and further parsing by the controller, then translation into a method call. In addition to promoting code re-use, this approach had the advantage of hiding the structure of the GIM protocol from the client, which increased the degree of modularity in the system.   

